kermit.columbia.edu/kermit.columbia.edu.tar/kermit.columbia.edu/newsgroups/misc.19971216-19980424/000045_news@newsmaster….columbia.edu _Sun Jan 4 04:50:36 1998.msg

Internet Message Format | 1998-04-22 | 5KB

Return-Path: <[e-mail]>
Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.35.30])
    by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id EAA13984
    for <[e-mail]>; Sun, 4 Jan 1998 04:50:36 -0500 (EST)
Received: (from news@localhost)
    by newsmaster.cc.columbia.edu (8.8.5/8.8.5) id EAA21498
    for kermit.misc@watsun; Sun, 4 Jan 1998 04:50:35 -0500 (EST)
Path: news.columbia.edu!panix!logbridge.uoregon.edu!news.maxwell.syr.edu!newsswitch.lcs.mit.edu!news.ultranet.com!not-for-mail
From: [e-mail] (John A Santos)
Newsgroups: comp.protocols.kermit.misc
Subject: Re: Problem with CKERMIT TRANSMIT
Date: Sun, 4 Jan 1998 04:38:20 -0500
Organization: UltraNet Communications, Inc.   http://www.ultranet.com/
Lines: 77
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
NNTP-Posting-Host: d19.dial-1.wal.ma.ultra.net
X-Complaints-To: [e-mail]
X-Ultra-Time: 4 Jan 1998 09:40:35 GMT
X-Newsreader: Anawave Gravity v2.00.753
Xref: news.columbia.edu comp.protocols.kermit.misc:8212

In article <[e-mail]>, jf mezei <"[non-
spam]jfmezei"@videotron.ca> says...
> John W. Manly wrote:
> > Hi, all.  I've been running into a very frustrating problem with the CKERMIT
> > TRANSMIT command when used over TCP/IP to a port other than the standard
> > TELNET port (port 23).
>
> > But the TRANSMIT operation never seems to work, though the rest of the
> > script does work.
>
> Been there, experienced the same thing. I fixed it wth the use of
> open read file.name
> :myloop
> read \%a
> if fail goto mydone
> output \%a\%13
> goto myloop
>
> :mydone
> close read
>
> Also, what I find most interesting is that sending \13 seems to result
> in
> \13\10 being sent !
>
> I am on VMS 5.5-2, CKERMIT 6.0.192 6 sep 96   (VAX, of course).
> TCP stack is CMU-IP.
>
We're using C-Kermit to talk to an SMTP server, using both output
and TRANSMIT commands.  The key (for OUTPUT) is you need to do
INPUT's to soak up the echoes and responses from the server.  SMTP
gives numeric response codes for various commands and errors;
we look for these in the responses to make sure everything is working.
The data (i.e. mail message) doesn't produce a response, just an echo.
I think it is the SMTP server that is echoing \13 as \13\10, not
Kermit sending \13\10.  Anyway, we were sending each line with a \13
and then waiting for the \13\10 in the response with an INPUT.

If you use TRANSMIT, it should soak up the echoes for you automatically
but it won't understand the protocol stuff.  I'm not familiar with
NNTP, but SMTP has some specific handshaking that you have to do with
the server and I think NNTP must be similar.  You need to send a
HELO hostname command, and wait for the response, to identify the sending
system.  Then you need to send a FROM: command and a TO: command,
identifying the sender and receiver's mail addresses, waiting for
responses in each case.  (I forget the precise order and format of
these commands...)  Then you need to send a DATA command.  The server
replies to the data command with a message telling you its okay to
start sending, and to terminate the message with a line with a single
period.  When we get this message, we send a text file with the formatted
mail message in it, using TRANSMIT.  After the transmit, we OUTPUT .\13
and wait for the SMTP server to say it got it (with another INPUT.)

There are a couple of gotcha's with SMTP that might apply to NNTP, too.
SMTP uses a line consisting solely of a period to indicate end-of-
message, so you have to stuff an extra period at the beginning of
any line starting with a period to avoid it seeing a false end-of-
message.  We do this in formatting the mail message file before
transmitting it.

The second gotcha is really a Kermit issue.  OUTPUT has an escape
mechanism: \number gets converted to an ASCII character whose value
is the number (e.g. \13 gets converted to <CR>), and \{special-char}
gets converted as well, where special-char is any of a list of
things.  For example, \n becomes a <null>, \\ becomes a single back-
slash, etc.  We need to suppress the translation to allow these literal
strings to appear in mail messages (\n wreaks havoc with C programs,
and all the substitutions occur with annoying frequency in MIME-encoded
documents.)  There is a work-around for this (can I mention it yet,
Frank?), but TRANSMIT doesn't have this problem, and is quite a bit
faster than a READ-OUTPUT-INPUT loop, so we use TRANSMIT for the body
of the message.

Hope this helps.

John Santos